Came out of a discussion with @bkueng. Just threw it up so I didn't forget. We should discuss in Tuesday maintainer call before pulling trigger.

Ok, keep me posted. FWIW I must be an old dog, because I don't see why you would want post underscores - the prefix more immediately tells you the variable is private.

Underscore prefix is a little controversial because there are some other rules that are a bit too close like in any scope underscore + uppercase is reserved, double underscore is reserved, and in a global namespace anything with underscore prefix could be reserved.

So even with all that I personally still have a mild preference for it, but let's just stop talking about the google style guide if we're going to carry all of these exceptions.

FYI this is why the state covariance matrix in EKF2, LPE, etc isn't _P, it will actually fail to compile on certain platforms.

Appreciate the explanation.

stop talking about the google style guide if we're going to carry all of these exceptions.

I think you're saying "lets not make this change because we want to stick to the guide as closely as possible"? If so, this is supposed to be discussed in the maintainer call.

I don't care what the rules are, but I think we should lint to enforce them.

@tstastny Did this get discussed/resolved in any way?

@tstastny Did this get discussed/resolved in any way?

shoot - i keep forgetting to bring it up in the dev calls. will put on the discussion list for next one.

Don't forget @tstastny :-)

@tstastny Looking for that comment in the dev call notes .... I guess you've forgotten that we'll both be at the PX4 developer day soon right and I can apply some menaces :-)

@tstastny Grrr :-)

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-november-07-2023/35031/1

From maintainer call: https://discuss.px4.io/t/px4-maintainers-call-november-07-2023/35031
@dagar please feel free to correct anything i got wrong here. again, I'm not terribly opinionated.. just want to lock it down so we don't have to think about it anymore, and have consistency.

• Abandon attempts to square with Google Style
• Update guide for what we are actually doing
  • e.g. some stragglers like file names (headers)
• Get linting set up FIRST so that we can actually enforce automatically (@MaEtUgR started this, we will need to find time to revisit and get it up and running)

@hamishwillee ok for you? i can revise the style guide for the main things we actually have traditionally cared about and intend to lint.

started this, we will need to find time to revisit and get it up and running

Clang format (only spacing): PX4/PX4-Autopilot#19855
Clang tidy I still have to spend some time.

@tstastny Thanks for the update.

Sounds sensible, in particular to get linting working first and have it be the canonical definition of our style guide. Once the PR is accepted would be great if you could update this guide and I can review.

As an aside, it doesn't appear to be "quite" Abandon attempts to square with Google Style since the clang setup is based on google. It is a good thing to be based as close to a documented style as possible.

FYI (and to you too @MaEtUgR ) we might also want to look at https://github.com/reviewdog/reviewdog . MDN use this tool to auto-lint changes made though github and add fixes as suggestions. It might not be useful for this, but I plan to integrate it into docs at some point.

No flaws found

This clarification is more correct than before since almost all code has this style right now. We still need to enforce by linting but this change has no disadvantage.

Works for me!